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(54) A method for performing a secure cashfree payment transaction and a cashfree payment 
system 



(57) A method for performing a cash-free payment 
transaction that comprises: 

a) a provider (PPPP) receives a pre-authorization 
message (2') for a payment made by a buyer (B), 
the pre-authorization message being authenticated 
for example by a personal identification number 

b) the provider (PPPP) generates a payment nonce 
in response to this pre-authorization message 

c) the provider (PPPP) forwards this payment 
nonce (3') to the buyer (B) and 

the provider (PP PP) approves the payment when asked 



or when being debited by a seller (S') interface. The 
method further comprises that the above mentioned 
steps are performed by a private pre-authorization and 
payment provider (PPPP) and that the provider (PPPP) 
accepts a pre-authorization message being sent by a 
buyer's personal trusted device (PTD) being independ- 
ent of the seller's interface and that the provider (PPPP) 
generates the payment nonce in a form which can be 
read by the seller's interface. 

This method using a personal trusted device (PTD) 
to obtain a nonce that protects privacy and prevents 
fraud being at the same time flexible enough to be used 
in different kind of transactions, even in off-line transac- 
tions. 




Printed by Jouve, 75001 PARIS (FR) 



1 



EP1 267 312 A1 



2 



Description 

Field of the invention 

[0001 J The invention relates to a method for perform- 
ing a secure cash-free payment transaction and a cash- 
free payment system in accordance with the preamble 
of claim 1 and claim 11 respectively. 

Description of the Prior Art 

[0002] There are a number of factors leading to an in- 
creased potential for abuse of people's personal and 
payment information and payment fraud, such as credit 
card fraud. With the growing acceptance of e-commerce 
and technologies to collect, store, sort, and analyze da- 
ta, there are increasing threats in this respect. Unfortu- 
nately, these concerns limit the growth of commerce on- 
line and also off-line and the acceptance of new tech- 
nologies that benefit both consumers and businesses. 
For example, using credit cards to make payments has 
enormous potential, but concerns about personal priva- 
cy and potential fraud greatly hinders acceptance and 
use thereof. 

[0003] It is known in the prior art to use credit card 
verification systems. It is also known, that the best way 
to ensure that credit card numbers cannot be used 
fraudulently is to never transmit the credit card number 
by any direct route, i.e. phone, mail, Internet or in written 
form. 

[0004] US-A-6'029'890 therefore suggests to use 
credit card numbers specifically tailored for one single 
purchase. A credit card owner has to request this special 
credit card number using an automated teller machine, 
where he has to enter a personal identification code, the 
desired credit limit for the expected financial transaction, 
the vendor number the credit must be sent at and a 
wanted expiration date shortly after the transaction due 
date. The automated teller machine is connected with a 
bank control system, the bank control system being con- 
nected to a credit provider. The credit provider is con- 
nected to vendor credit card interfaces. The bank control 
system asks, after having approved the desired credit 
limit, the credit provider for an individual credit card 
number, which is transmitted to the credit card owner 
from the credit card provider through the bank control 
system and through the automated teller machine. The 
credit card owner then has to type the credit card 
number into the credit card interface at the vendors 
place to authorize the financial transaction or to transmit 
the individual credit card number to the vendor. 
This method bears several disadvantages. First of all, 
the credit card owner has to find an automated teller ma- 
chine. Usually, automated teller machines are not pro- 
vided in shops, enforcing the buyer to leave the shop 
and to search a teller machine after having chosen a 
product to buy. This complicates the buying transaction 
and can especially not be used in environments not be- 



ing familiar to the customer, for example as they are en- 
countered by the customer when being on vacation. Fur- 
thermore, the communication is quite complicated, in- 
volving teller machines, bank control systems and credit 

5 card providers. This will also be even more complicated 
when the customer is abroad, i.e. when the local bank 
control system may not be connected to the bank control 
systems normally used by the customer. 
[0005] WO 00/49586 also suggests to use limited-use 

10 credit card numbers. In this system, a pool of credit card 
numbers are maintained which share identical format- 
ting. One of these credit card numbers is assigned to be 
a master credit card number, the others are assigned to 
be limited-use credit card numbers. The limited-use 

15 credit card numbers are sent to the credit card owner 
en-bloc, for example on a list or on individual credit 
cards. However, these numbers are not yet activated, 
but can be activated by the credit card owner when he 
wants to perform a financial transaction. To activate a 

20 card, the owner has to communicate with the credit card 
issuer before using it in a transaction. This systems also 
seems to be quite complicated, since the credit card 
owner has to book-keeping the credit card numbers al- 
ready used and the one still being available. Further- 

25 more, instead of carrying with him one single credit card 
he has to cope with several of them or at least with sev- 
eral numbers. 

Summary of the invention 

30 

[0006] It is therefore an object of the invention to pro- 
vide a method for performing a secure cash-free pay- 
ment transaction and a cash-free payment system, 
which enables a secure transaction in a simpler way and 

35 which can be used with different paying systems. 

[0007] This object is achieved with a method for per- 
forming a secure cash -free payment transaction and a 
cash-free payment system with the features of claim 1 
and claim 1 1 respectively. 

40 [0008] The inventive method for performing a secure 
cash-free payment transaction and the inventive cash- 
free payment system allow a buyer to obtain a pre-au- 
thorization for payments privately on a buyer controlled 
channel, preferably a mobile phone or another wireless 

45 device, and then complete payment for a transaction in 
an online or offline environment. In thepre-authorization 
a one-time credit card number or another nonce is ob- 
tained from a private p re-authorization and payment 
provider chosen by the buyer and the transaction is 

50 made with this nonce. Since the pre-authorization chan- 
nel is separated from channels used and controlled by 
sellers, absolute privacy for the buyer is guaranteed. He 
has not to disclose any private information which would 
enable the seller to identify him. 

55 [0009] The use of a wireless device, especially a mo- 
bile phone, for communicating with the provider enables 
an easy way of communication, which can be used by 
the buyer on all places of the world. 
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[0010] Furthermore, the use of a wireless device also 
renders the payment system flexible. The same system 
can be used with different kind of seller's payment sys- 
tems. 

Brief description of the drawings 

[0011] The present invention will be more readily un- 
derstood upon reading the following detailed description 
in conjunction with the drawings in which: 

Figure 1 shows a cash -free payment system with a 
proxied on-line internet transaction; 

Figure 2 shows a cash-free payment system with a 
transaction where a regular credit card is 
Used to pay the seller thus the seller infra- 
structure is unchanged; 

Figure 3 shows a first variant of a cash-free payment 
system without using a credit card and a 
changed seller infrastructure and 

Figure 4 shows a second variant of a cash -free pay- 
ment system without using a credit card a 
changed seller infrastructure. 

Description of the preferred embodiments 

[0012] The inventive method can be used in different 
payment systems, such as on-line and off-line systems, 
systems requiring credit card numbers and systems 
working with other kind of identification numbers. In the 
following, the inventive method and the inventive cash- 
free payment system are described in use with some of 
these payment systems. 

[0013] Based on this figure 1 , a first variant of the in- 
ventive method for performing a secure credit card 
transaction is described, wherein the purchase is han- 
dled using e-commerce. 

[0014] In the first step 1 , a buyer B shops via Internet 
in an eStore S using a proxy. The proxy is an entity, that 
enables private e-commerce transactions by providing 
protection of personal and payment information during 
all transaction steps. It means during pre-sales, i.e. 
browsing, during check-out, during fulfillment and after 
sales. During check-out, the Proxy's credit card is pre- 
sented to the eStore and not the customer's. During ful- 
fillment the proxy can guarantee private shipping as a 
premium service. After sales, follow-up e-mails are sent 
in an anonymous way as well as phone support is guar- 
anteed via anonymous phone relay or a private call cent- 
er. Due to its uniform checkout across eStores, it can 
enable groups of sellers or eStores S for new methods 
of payment without requiring the seller to support that 
method of payment itself. Shopping through proxy in- 
cludes any and all of the following: 



(i) shopping through a proxy's privacy portal; 

(ii) shopping through a privacy portal created by the 
proxy for a third party; 

(iii) shopping through a third party that uses the 
5 proxy's systems; or 

(iv) shopping at a third party, such as a seller, that 
provides a link to the proxy that allows for some form 
of private check-out. 

10 [0015] When the buyer B has chosen an item to buy, 
he has to pay the proxy before it allows for delivering. 
At this final check-out page, the proxy provides a card- 
type in addition to the known credit card types such as 
Visa, MasterCard and American Express. This addition- 
's al card-type is related to a private p re-authorization and 
payment provider PPPP described later-on. This card- 
type also requires a number, which can adhere to the 
common credit card format. It can also have a different 
format, such as a cryptographic string or a phone 
20 number. 

[0016] If the buyer B chooses to use the provider 
PPPP, he needs a personal trusted device PTD. With 
this device PTD he requests in a second step 2 a single 
transaction credit card number or another nonce from 

25 the provider PPPP. The PTD device is a device used to 
store information on behalf of the user and communicate 
over various channels. Preferably, it is a wireless phone. 
It can also be a Web-enabled palm pilot or the personal, 
internet-connected PC of the buyer B. The user prefer- 

30 ably keeps control over the PTD device altogether with 
a device access password. 

[0017] With this PTD device he submits the purchase 
amount securely to the PPPP. Securing such a link is a 
well-understood art: One embodiment would require the 

35 user to use some form of security, such as a personal 
identification number, i.e. a PIN, or a one-time PIN from 
a list previously obtained from the PPPP in a secure 
way. If a PTD is programmable, any kind of secure sign- 
on/password authentication protocol could be used in- 

40 stead. For the submission of this information to the pro- 
vider PPPP, several methods can be used: 

a) a wireless data transmission method protected 
by a wireless transport layer security standard, such 

45 as WTLS, an "always-on" packet-switched GPRS, 
a connection-based WAP, or later generation stand- 
ards such as UMTS; 

b) a short message service message such as SMS 
or a WAP notification or 

50 c) a voice channel reaching an integrated voice re- 
sponse unit. The last method has the advantage 
that there is some degree of confidentiality for voice 
calls while the security implementations of WAP 
gateways and browsers are only partially complete 

55 at best, i.e. end-to-end WTLS or reliable WTLS to 
SSL translation is not generally available yet. 

[001 8] In a third step 3, the provider PPPP authorizes 
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the transaction and creates a time-limited number or 
one-time number, called nonce, for payment as well as 
an expiration date. In a variant of the invention, both ad- 
here to the credit card format thus including also a card- 
holder name that is unrelated to the buyer's name. 
This nonce and the expiration date is sent to the PTD 
device of the buyer B. 

The provider PPPP is an entity known to the buyer B, 
the provider having access to the personal data of the 
buyer B enabling the provider PPPP to authorize finan- 
cial transactions. The provider PPPP can be an issuing 
bank that provides credit cards. For purposes of this in- 
vention, providers PPPP could also include the proxy, 
cellular service providers, or any other entity that can 
effectively bill many customers. 

[001 9] The nonce sent to the buyer must have the fol- 
lowing properties: It has to be i) fresh or recent, ii) hard 
to guess, Hi) unique and iv) have a value limited to the 
transaction amount. 

[0020] In a fourth step, the buyer B enters the nonce 
into the proxy checkout page and resumes the transac- 
tion. If the PTD device and the buyer's B computer en- 
abling the internet access have a way of electronically 
communicating, for example by means of a short-range 
infrared protocol (BlueTooth, etc.), the nonce could be 
transmitted without the end-user needing to remember 
and reproduce it, as shown in figure 1 with the dashed 
line 40.. 

As long as there is still a need for the user to tell, type 
or otherwise transmit this number at any time during the 
execution of the protocol, the nonce should be human 
readable and memorizable. 

[0021] if a nonce is to be emulated with real credit card 
numbers the following method is preferably used: The 
P PPP reserves itself a large pool of credit card numbers, 
preferably a bank identifier number BIN. A BIN repre- 
sents many millions of valid credit card numbers. Be- 
cause sellers are not always capable of shipping the en- 
tire set of goods purchased in one package, the velocity 
must not be limited to one but a small number unless 
the PPPP can tailor to the characteristics of the seller at 
hand. This allows for partial shipments, authorizations, 
and settlements. Unused pre-authorizations shall be ex- 
pired by setting back the "open-to-buy" value to zero af- 
ter a grace period. Normal credit cards furthermore do 
not show the above mentioned properties i) and iv). The 
preferred method to achieve these two properties is to 
set the "open to buy" value, i.e. the available credit, to 
zero by default and only in the course of the protocol set 
it to the transaction amount in real time achieving prop- 
erty iv). If the card issuer is unable to perform such a 
real-time update of their card-base, the PPPP antici- 
pates the expected transaction amounts and randomly 
distributes them over the available card pool in batch 
mode prior to the usage of the cards. In the course of 
the protocol, the transaction amount will be one of the 
key determining factors for selecting the nonce out of 
the pool of unused card numbers. After the usage of the 



card number for a transaction, its "open-to-buy" value 
will be reset to zero and it will not be used for an amount 
of time that is hard to predict until it re-enters the pool 
of available good card numbers, thus approximating the 

5 above mentioned property i). Therefore, all parties that 
have seen a card used in a transaction before are un- 
likely to be able to re-use it in an illegitimate way be- 
cause it is hard to guess when it becomes usable again. 
The management of a card pool according to this meth- 

io od will yield heuristics that allow efficient p re-allocation 
of open to buy amounts and short recycle times while 
keeping fraud minimal. 

[0022] In a fifth step 5, the proxy routes the authori- 
zation requests depending on the credit card type: reg- 

15 ular cards go to proxy's credit card merchant bank, 
whereas PPPP transactions go to the appropriate PPPP 
through a state-of-the-art secure connection, such as 
XML over https, and are processed in the similar way 
as regular seller authorizations and settlements. 

20 [0023] After successful authorization a regular proxy 
check-out is executed on behalf of the buyer B, using 
the single transaction credit card number obtained from 
the PPPP, as shown in figure 1 with reference number 6. 
[0024] In a last step 7, the provider PPPP sends the 

25 buyer B a receipt via e-mail, SMS, a WAP-push or alike 
containing an authenticator for potential subsequent 
customer service interactions. For example, the last five 
digits of the nonce are used. Preferably, this receipt is 
electronically signed by the provider PPPP and if avail- 

30 able encrypted with a buyer's public key. In a first vari- 
ant, the receipt is sent to the buyer B over another chan- 
nel than the PTD device to further minimize fraud. In a 
second variant, it is sent over the PTD device. 
[0025] In another variant of the inventive method, a 

35 cryptograph ically more secure method is used: in the 
third step 3, the nonce sent to the buyer B by the provider 
PPPP is computed as a hash of the receipt. Then, in this 
last step 7, the receipt is sent to the buyer B. The buyer 
B hashes the receipt and compares it to the number 

40 mentioned above. 

[0026] In the above-mentioned method, the buyer B 
has never disclosed his real credit card number on the 
Internet. If the provider PPPP settles with the buyer B 
directly, no credit card is used at all. 

45 [0027] Based on figure 2, it will now be described how 
the inventive idea is used in a transaction, wherein a 
regular credit card is used to pay the seller th us the seller 
infrastructure is unchanged. 

[0028] When the buyer B has made his decision of a 
50 product to buy, he is presented in a first step 1 ' with the 
amount to be paid by a seller S'. This seller S' can now 
be either a physical store, contacted physically by the 
buyer or an eStore contacted through Internet. In the 
latter case, the contact has been established directly, 
55 not using a proxy. Optionally, the seller can also give the 
buyer B, in addition to the amount due, a merchant cat- 
egory code, a seller or seller location identification or 
the like as well. 
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[0029] In a second step 2* he uses his PTD device to 
ask for a one-time credit card number or another nonce. 
This step is similar to the second step 2 described in the 
on-line transaction. In addition this request step also 
contains at least the following options to choose from 
regarding complementary information to be returned: 

a) no billing and shipping information is needed; 

b) provide the provider PPPP billing address to pre- 
serve the privacy of the buyer's billing address; 

c) provide the provider PPPP billing address and a 
private shipping address or 

d) assign the buyer's billing or another verified ad- 
dress to the nonce. This is for the case that the seller 
S' will only ship to the billing address. If the buyer B 
is highly trusted by the provider PPPP, also an ar- 
bitrary shipping address could be made the billing 
address of the nonce. The provider PPPP also may 
maintain an address book on the behalf of the buyer 
B. 

[0030] In a preferred variant, the usability of the nonce 
to be provided is restricted further here by specifying the 
seller category or even the exact seller name, the exact 
seller location, or a product identification. 
[0031 ] In a third step 3', the nonce is sent to the buyer 
B in the form of a valid credit card number. Furthermore, 
in response to the choice made in the second step 2\ 
the information provided can be complemented with a 
corresponding billing address compliant with an ad- 
dress verification system, such as AVS, and/or a private 
shipping address. All this information is preferably pre- 
sented in such a way that form-filling applications such 
as Gator can easily pick it up and re-use it to fill the 
checkout form at an arbitrary seller. In one embodiment, 
this could be achieved by presenting all the information 
in this flow also as hidden HTML input fields optionally 
named according to the ECML standard. Additionally 
the form-filler could maintain a history of how the one- 
time cards were deployed on behalf of the user. Initially, 
this will mainly be relevant for the situation where the 
nonce is requested from a computer tied to the Internet. 
Once form-fillers go wireless the equivalent of hidden 
HTML input fields can be provided (e.g. "setvar" in 
WML). 

[0032] In a fourth step 4\ the buyer B uses the nonce 
to complete his transaction. As mentioned above, this 
can be phone orders, eStores* Internet checkouts or a 
physical appearance in a traditional store. The latter 
stores are normally equipped with a credit card inter- 
face. These interfaces usually have a keyboard for entry 
of a credit card number and an expiration date in case 
of malfunctioning magnetic stripes. If the PTD device 
and the credit card interface terminal have a way of elec- 
tronically communicating as mentioned above, the 
nonce can be transmitted without the buyer B needing 
to remember and reproduce it. This is shown in figure 2 
with a dashed line 40'. The transaction then continues 



like a regular credit card transaction at the seller S\ 
[0033] The inventive method also enables financial 
transactions without using credit cards. In this case the 
seller S", S"' has to be able to route to the provider PPPP 

5 without using the standard payment backbone formats 
or infrastructure in place or that the seller's S", S'" infra- 
structure and the underlying payment backbone can be 
changed to bring a transaction authorization to the seller 
S", S"' without the seller S", S"' obtaining information 

10 authenticating the buyer B. 

[0034] Based on figure 3, it will now be described how 
the inventive idea is used in a first variant of a transac- 
tion, where the buyer B is not using a credit card with 
the seller. 

15 [0035] This variant is advisable among other if the 
provider PPPP is unable to secure a large enough pool 
of credit card numbers to emulate nonces. 
[0036] The first to fourth steps 11,12,13,14,14' are 
identical to the first to fourth steps 1,2,3,4,40 of the 

20 method shown in figure 1 . In the fifth step 15, the seller 
S" or the seller's bank presents the nonce to the provider 
PPPP. This implies additional routing in the credit card 
backbone or a separate routing infrastructure for the 
nonces. In a sixth step 1 6 the provider PPPP authorizes 

25 the nonce like a regular issuing bank enabling the trans- 
action to be finished. 

[0037] Based on figure 4, it will now be described how 
the inventive idea is used in a second variant of a trans- 
action, where the buyer B is not using a credit card with 

30 the seller. 

[0038] In a first step 1 1 ', where the buyer B has made 
his decision, he obtains a routing identifier, for example 
in the form of a telephone number, from the seller S'". 
This information can for example be displayed on its 

35 credit card interface. Similarly to the previous step 40, 
this number could be transmitted from the seller S to the 
PTD without B needing to remember and re-type it (step 
14"). In a second step 22 the identifier and the amount 
are entered into the PTD device and sent to the provider 

40 pppp. in the third step 33, the provider PPPP authorizes 
it and pushes this authorization information to the seller 
S"\ The seller S"' releases in a fourth step 44 the goods 
and in a fifth step 55, the provider PPPP sends the buyer 
B or its PTD device a receipt with at least 5 digits as 

45 placeholders for the credit card number to access Proxy 
customer service. 

[0039] The inventive method for performing a private 
and secure payment transaction and the inventive pay- 
ment system using a personal trusted device to obtain 
50 a nonce protect privacy and prevent fraud being at the 
same time flexible enough to be used in different kind 
of transactions. 



1 . A method for performing a cash-free payment trans- 
action wherein 
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a) a provider receives a pre-authorization mes- 
sage for a payment to be made by a buyer, the 
pre-authorization message being authenticat- 
ed by a personal identification token 

b) the provider generates a payment nonce in 
response to this pre-authorization message 

c) the provider forwards this payment nonce to 
the buyer and 

d) the provider approves the payment when 
asked or when being debited by a seller inter- 
face, 

characterized In 

that the above mentioned steps are performed by 
a private pre-authorization and payment provider 
PPPP, 

that the PPPP accepts a pre-authorization mes- 
sage being sent by a buyer's personal trusted de- 
vice being independent of the seller interface and 
that the PPPP generates the payment nonce in a 
form which can be read by the seller interface. 

2. The method of claim 1 , wherein the pre-authoriza- 
tion message is sent by a mobile phone. 

3. The method of claim 1 , wherein the pre-authoriza- 
tion message is received by the PPPP through wire- 
less data transmission such as SMS, GPRS or WAP 
notify. 

4. The method of claim 1 , wherein the payment nonce 
is sent to the buyer's personal trusted device using 
wireless data transmission such as SMS or voice. 

5. The method of claim 1 , wherein the payment nonce 
is complemented in a way re-deployable for form 
filling applications by a private billing address with- 
out a reference to a buyer's real billing address that 
is compatible with the AVS and/or a private shipping 
address for use in an anonymous shipping service. 

6. The method of claim 1 , wherein the payment nonce 
is received by the seller through one of the group of 
wireless data transmission, electronic communica- 
tion and manual data entering through a keyboard. 

7. The method of claim 5, wherein the payment nonce 
is received by the seller from the buyer or from the 
provider or the proxy. 

8. The method of claim 1 , wherein the provider gener- 
ates the payment nonce when having received the 
pre-authorization message comprising at least a 
seller identification. 

9. The method of claim 1 , wherein the provider gener- 
ates a payment nonce when having received an in- 
formation concerning the sellers interface, the form 



of the payment nonce being dependent on the sell- 
ers interface. 

10. The method of claim 1 , wherein the provider gener- 
5 ates as a payment nonce at least one of the group 

of a credit card number and another credit identifi- 
cation number. 

11. A cash-free payment system comprising 

10 

a) means to receive a pre-authorization mes- 
sage for a payment made by a buyer and to val- 
idate an authentication token sent with this 
message, 

is b) means to generate a payment nonce in re- 

sponse to this pre-authorization message 

c) means to forward the payment nonce to the 
buyer and 

d) means to approve the payment when asked 
20 or when being debited by a seller interface, 

characterized In 

that the means are part of a private pre-authoriza- 
tion and payment provider PPPP, 
25 that the means to receive a pre-authorization mes- 
sage accepts a message being sent by a buyer's 
personal trusted device being independent of the 
seller interface and 

that the means to generate the payment nonce gen- 
30 erate it in a form which can be read by the seller's 
interface. 
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